Data recording method, data editing method, data decoding method, and apparatus and recording medium therefor

ABSTRACT

A system records an AV stream composed of a plurality of record units (RUs) containing independently reproducible video units (VUs) of at least video or audio and program information (Movie atom) managing the AV stream, onto a recording medium. The program information contains a piece of information (Edit list atom) that manages a point of junction between the record units or between AV streams. In decoding the AV stream, decoding is halted or decoders are switched at the point of junction, based on the management information on the points of junction, for example.

TECHNICAL FIELD

The present invention relates to a data recording method, a data editingmethod and a data decoding method and an apparatus therefor, forrecording and reproducing data such as video data and audio data to andfrom a random-accessible recording medium such as a hard disk, opticaldisk, etc.

BACKGROUND ART

Digital recording and reproducing apparatuses for video and audio usingdisk media have been coming into wide use. One of the featured functionsof disk media, distinct from tape media, is the function ofnon-destructive editing, or also called the function of non-linearediting. This function is to provide the capability of reproducing anysections of AV streams in a desired order without actual movement orcopy of the AV streams recorded on the disk, and this function isachieved by creating information (playback management information) thatindicates the start and end of every section to be reproduced in AVstreams and their order of reproduction and implementing reproductionfollowing that information.

In this way, with such disk media, it is possible to make an editwithout rewriting source material or moving the data. However, there aresome cases where the source material needs to be directly edited. Forexample, suppose the non-destructive edited result is wanted to bebrought together into a single file for easy handling by a personalcomputer (PC). In this case, only that being used in the edited resultshould be picked out from associated AV streams and united into a singlefile.

There is also a case where an intermediate part that is unnecessary inan AV stream is wanted to be deleted in order to increase the emptycapacity of the disk. In this case, the parts located before and afterthe intermediate part should be united.

For either case, plural AV streams should be put together. However,there is a concern that some reproduction noise might occur at the seamwhen a video data encoding scheme based on the MPEG video standard(ISO/IEC 11172-2 or ISO/IEC 13818-2) is adopted.

The reason is as follows. The MPEG video standard adopts variable lengthcoding, and this specifies that encoding of data to be coded at apredetermined rate is implemented such that a model hypothetical decodercalled VBV (Video Buffering Verifier) which should be connected to theoutput from the encoder will not overflow or underflow.

In this model, coded data is supplied to the VBV buffer at a rate notgreater than the aforementioned predetermined rate, and the amount ofdata occupied in the VBV increases at that rate. On the other hand, themoment one frame or field has been decoded, the occupancy of datadecreases instantly by the amount of the corresponding coded data.

Any coded data based on MPEG video cannot be assured to be reproducedcorrectly if the data has not been encoded in such control that the VBVbuffer will not overflow or underflow even if the amount of datarepeatedly increases and decreases, as shown in FIG. 22. The risk ofreproduction noise when some pieces of video data are joined can beattributed to the possibility of the VBV buffer causing overflow orunderflow at a point of the seam.

The reason for the collapse of the VBV buffer at the seam will bedescribed referring to an example. Here, description is made of a casewhere the front part before time OUT of coded video data A having atime-dependent variation in the occupancy of the VBV buffer shown inFIG. 23( a) and the rear part after time IN of coded video data B shownin FIG. 23( b) are joined.

FIG. 23( c) is the joined result. It is understood that in this case thebuffer underflows because a frame or field containing a large amount ofcoded data takes place right after the point of junction regardless ofthe low buffer occupancy right before the joined point. The reason whyan event of this kind happens is that there is a possibility that theconformity of the buffer occupancy is lost.

In order to solve the above problem, Japanese Patent ApplicationLaid-open Hei 9 No. 182024 proposes a technique of preventing underflowby increasing the transfer speed of the input data to the decoder.However, this method needs a special decoder, resulting in costdisadvantage.

As another method, Japanese Patent Application Laid-open Hei 8 No.251582 proposes a technique (re-coding) whereby the seam portion uponjoining is once decoded and then encoded again so that the amount of thecoded data will be kept so as not to cause corruption of the VBV buffer.However, in this case, there is a concern of occurrence of imagedegradation due to the re-coding process. Further this method needs toimplement coding and decoding successively or in parallel, entailing theproblem in that the apparatus becomes more complicated.

The present invention has been devised in view of the above problems, itis therefore an object of the present invention to provide a datarecording method, a data editing method and a data decoding method aswell as a data recorder and a data decoder, which, by a simpleconfiguration, can prevent reproduction noise upon reproduction of an AVstream which is formed of joined AV streams.

DISCLOSURE OF INVENTION

The first invention of the present application is a data recordingmethod for recording a second unit composed of a plurality of firstunits containing first data having at least video or audio and a firstprogram that manages the second unit, onto a recording medium, and ischaracterized in that the first program contains information thatmanages a point, of junction between the first units.

The second invention of the present application is characterized in thatthe point of junction is a site where arbitrary pieces of the first dataare deleted from the second unit.

The third invention of the present application is characterized in thatthe second unit is managed by a single file.

The fourth invention of the present application is characterized in thatthe first data of video is encoded data of the video based on a MPEGstandard.

The fifth invention of the present application is a data editing methodfor producing a second unit by connecting a first unit containing firstdata having at least video or audio and a third unit containing seconddata having at least video or audio and is characterized in that a firstprogram that manages the second unit contains information that manages apoint of junction between the first unit and the third unit.

The sixth invention of the present application is characterized in thatthe first unit and the third unit are formed by deleting arbitrarypieces of the first data from the second unit.

The seventh invention of the present application is characterized inthat the second unit is managed by a single file.

The eighth invention of the present application is characterized in thatthe first and second data of video is encoded data of the video based ona MPEG standard.

The ninth invention of the present application is a data decoding methodfor decoding a second unit composed of a plurality of first unitscontaining first data having at least video or audio, in accordance witha first program that manages the second unit, and is characterized inthat the first program contains information that manages a point ofjunction between the first units, and decoding of the first units iscontrolled with reference to the information on the point of junction.

The tenth invention of the present application is characterized in thatdecoding control of the first units is achieved by halting the decodingat the point of junction.

The eleventh invention of the present application is characterized inthat decoding control of the first units is achieved by switchingdecoders before and after the point of junction.

The twelfth invention of the present application is characterized inthat the first and second data of video is encoded data of the videobased on a MPEG standard.

The thirteenth invention of the present application is a data recordingdevice for recording a second unit composed of a plurality of firstunits containing first data having at least video or audio and a firstprogram that manages the second unit, onto a recording medium, and ischaracterized in that the first program contains information thatmanages a point of junction between the first units.

The fourteenth invention of the present application is a data editingdevice for producing a second unit by connecting a first unit containingfirst data having at least video or audio and a third unit containingsecond data having at least video or audio, and is characterized in thata first program that manages the second unit contains information thatmanages a point of junction between the first unit and the third unit.

The fifteenth invention of the present application is a data decodingdevice for decoding a second unit composed of a plurality of first unitscontaining first data having at least video or audio in accordance witha first program that manages the second unit, and is characterized inthat the first program manages information on a point of junctionbetween the first units, and the data decoding device comprising: adecoder for the first units for controlling the decoding based on theinformation on the point of junction.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram showing a schematic configuration of a videodisk recorder in the embodiment of the present invention.

FIG. 2 is an illustrative view showing the relationship between themanagement information in the QuickTime file format and AV streams.

FIG. 3 is an illustrative view showing the scheme of a Movie atom in theQuickTime file format.

FIG. 4 is an illustrative view showing the scheme of a Track atom in theQuickTime file format.

FIG. 5 is an illustrative view showing the scheme of a Track header atomin the QuickTime file format.

FIG. 6 is an illustrative view showing the scheme of a Media atom in theQuickTime file format.

FIG. 7 is an illustrative view showing the scheme of a Media informationatom in the QuickTime file format.

FIG. 8 is an illustrative view showing an example of data management bya Sample table atom.

FIG. 9 is an illustrative view showing the scheme of a Sample table atomin the QuickTime file format.

FIG. 10 is an illustrative view showing the scheme of an Edit atom inthe QuickTime file format.

FIG. 11 is an illustrative view showing an example of playback rangedestination by an Edit atom.

FIG. 12 is an illustrative view showing the scheme of a User-defineddata atom in the QuickTime file format.

FIG. 13 is an illustrative view showing a stream structure in the firstembodiment of the present invention.

FIG. 14 is an illustrative view showing a VU structure in the firstembodiment of the present invention.

FIG. 15 is an illustrative view showing an AV stream managementstructure based on QuickTime in the first embodiment of the presentinvention.

FIG. 16 is a flowchart showing the recording operation in the firstembodiment of the present invention.

FIG. 17 is an illustrative view showing a joined state of AV streams inthe first embodiment of the present invention.

FIG. 18 is an illustrative view showing the first example of aninformation structure that manages the junction of AV streams in thefirst embodiment of the present invention.

FIG. 19 is an illustrative view showing the second example of aninformation structure that manages the junction of AV streams in thefirst embodiment of the present invention.

FIG. 20 is an illustrative view showing the third example of aninformation structure that manages the junction of AV streams in thefirst embodiment of the present invention.

FIG. 21 is a flowchart showing the playback operation in the firstembodiment of the present invention.

FIG. 22 is an illustrative view showing an example of change in theoccupancy of the VBV buffer.

FIG. 23 is an illustrative view showing an example of the junction ofMPEG video streams according to the prior art.

BEST MODE FOR CARRYING OUT THE INVENTION

Herein, the embodiments of the present invention will be described indetail with reference to the drawings.

<System Configuration>

FIG. 1 shows a configuration of a video disk recorder capable ofdubbing, used in common in the embodiments herein. As shown in FIG. 1,this apparatus is comprised of a bus 100, a host CPU 101, RAM 102, ROM103, a user interface 104, a system clock 105, an optical disk 106, apickup 107, an ECC decoder 108, an ECC encoder 109, a playback buffer110, a recording/dubbing buffer 111, a demultiplexer 112, a multiplexer113, a multiplexing buffer 114, an audio decoder 115, a video decoder116, an audio encoder 117, a video encoder 118 and unillustrated camera,microphone, speaker, display and the like.

Host CPU 101 communicates through bus 100 with demultiplexer 112,multiplexer 113 and pickup 107 as well as audio decoder 115, videodecoder 116, audio encoder 117 and video encoder 118, though not shown.

Upon reproduction, data read out from optical disk 106 by means ofpickup 107, is error corrected by ECC decoder 108 and stored temporarilyinto playback buffer 110. Demultiplexer 112, in accordance with datatransmission requests from audio decoder 115 and video decoder 116,distributes the data in the playback buffer to associated decodersdepending on the types.

In recording, compression-coded data by audio encoder 117 and videoencoder 118 is once sent to multiplexing buffer 114, AV-multiplexed bymultiplexer 113 and then sent to recording/dubbing buffer 111. Data inrecording/audio dubbing buffer 111 is added with error correction codeby ECC encoder 109, then is recorded onto optical disk 106 via pickup107.

The coding scheme for audio data employs MPEG-1 Layer-II while thecoding scheme for video data employs MPEG-2.

The optical disk 106 is assumed to be a removable optical disk which isrecorded and played back spirally from the periphery toward the center.One sector is made up of 2048 bytes and sixteen sectors form one ECCblock for error correction. If any data in an ECC block needs to berewritten, it is necessary to read out the whole ECC block containingthat data, subject it to error correction, renew the target data, adderror correction codes to the data again to reconstruct an ECC block andrecord it onto the recording medium.

Further, in order to improve the recording efficiency, ZCAV (ZoneConstant Angular Velocity) is adopted so the recording area is composedof multiple zones having different rotational rates.

<Filesystem>

A filesystem is used to manage various pieces of information on opticaldisk 106. As the filesystem here, UDF (Universal Disk Format) is usedtaking into account joint operation with PCs. On the filesystem, eachpiece of management information and an AV stream is handled as a file.The user area is managed by logical blocks of 2048 bytes (one to onecorrespondent with the sectors).

Each file is composed of an integer number of extents (consecutivelogical blocks) and can also be dispersed out and stored in extentunits. The empty areas are managed in logical block units using SpaceBitmap.

The information showing extents, the Space Bitmap, the managementinformation as to the filesystem and the like are recorded on opticaldisk 106.

<File Format>

As the format for management of AV streams, the QuickTime file format isused. The QuickTime file format was developed as a format for multimediadata management by Apple Computer, Inc., and is widely used in the PCworld.

The QuickTime file format is composed of video data, audio data and thelike (these are also called media data) and management information. Thecombination of these two is herein called a QuickTime movie (abbreviatedas movie). The two may be present in the same file or in differentfiles.

When present in the same file, they constitute a file 201 shown in FIG.2( a). Each piece of information is stored as a common structure calledan atom. The management information is stored as a structure calledMovie atom. The AV stream is stored as a structure called Movie dataatom.

It should be noted that a Movie atom is a kind of program informationfor controlling playback of arbitrary sections of media data in anarbitrary order, and includes a table for providing a relative position,in the file, of the AV data that corresponds to an arbitrary time in themedia data, the attribute information of the media data, and externalreference information, which will be described hereinbelow.

When management information and media data are stored in differentfiles, they constitute a structure of files 202 and 203 shown in FIG. 2(b). The management information is stored as a structure called Movieatom while the AV stream is not needed to be stored as an atom. In thissituation it is termed that the Movie atom ‘externally refers’ to file203 holding the AV stream.

External reference, as shown in FIG. 2( c), can be made such that theMovie atom of file 204 can refer to AV stream files #1 and #2 disposedin plural files 205 and 206. This structure enables so called‘non-linear editing’ or ‘non-destructive editing’ which achievessimulated editing without making physical movement of any AV streams.

Now, the QuickTime management information format will be described withreference to FIGS. 3 to 12. To begin with, the common informationstorage format, i.e., atom, will be explained. Each atom necessarilyincludes Atom size that indicates the size of the atom and Type thatindicates the type information of the atom at the front thereof. Type isrepresented with four characters, for example, ‘moov’ depicts a Movieatom, ‘mdat’ a Movie data atom.

Each atom can contain another atom. That is, atoms can constitutelayered structures. FIG. 3 shows the structure of a Movie atom. A Movieheader atom manages the overall attributes of the movie which the Movieatom manages. A Track atom stores the information as to the track ofvideo, audio and the like contained in that movie. A User-defined dataatom is an atom which can be defined in a free fashion.

FIG. 4 shows the structure of a Track atom. A Track header atom managesthe overall attributes of the track. An Edit atom manages at what timinga section of media data should be reproduced in the movie. A Trackreference atom manages the relationship with other tracks. A Media atommanages actual data such as video and audio data.

FIG. 5 shows the structure of a Track header atom. Here, descriptionwill be made as to only those needed hereinbelow. ‘Flags’ is a group offlags indicating attributes. As a typical example, Track enabled flagcan be mentioned. If this flag is 1, the track is reproduced while thetrack is not reproduced if it is 0. Layer indicates the spatial priorityof the track. If there are multiple tracks that display images, thesmaller the layer value of a track, the more to the foreground thecorresponding image is displayed.

FIG. 6 shows the structure of a Media atom. A Media header atom managesthe overall attributes etc. as to the media data the Media atom manages.A Handler reference atom stores information that represents whichdecoder the media data should be decoded by. A Media information atommanages attribute information unique to the media such as video, audioetc.

FIG. 7 shows the structure of a Media information atom. A Mediainformation header atom manages attribute information unique to themedia such as video, audio etc. A Handler reference atom is thatexplained in the Media atom paragraph. Data information atom contains aData reference atom, which is the atom that manages the names of filescontaining media data to which the QuickTime movie refers. A Sampletable atom manages the size of data, playback time and the like.

Next, a Sample table atom will be described. However, before thisdescription, the data management scheme in QuickTime will be describedwith reference to a file 801 shown in FIG. 8. In QuickTime, the minimumunit of data (e.g., video frame) is called a sample. In each track, eachsample is allotted with a number (sample number) starting from 1, in theorder of playback time sequence.

The QuickTime format manages the playback time length and data size ofeach sample. An area in which samples belonging to the same track isarranged consecutively in a file in the order of playback time sequenceis called a chunk. Each chunk is also allotted with a number startingfrom 1 in the order of playback time sequence.

The QuickTime file format also manages the address of each chunk fromthe front of the file and the number of samples belonging to each chunk.Based on these pieces of information, it is possible to determine theposition of a sample corresponding an arbitrary point of time.

FIG. 9 shows the structure of a Sample table atom. A Sample descriptionatom is a table that manages the data formats of individual chunks, theindexes of files in which samples are stored, and the like. In thistable, if samples are stored in different files or if there isdifference in data format or in other aspects, such cases are managed bydifferent entries in the table. Here, the entry is a unit of informationwhich is referred to by other information.

A Time-to-sample atom manages the playback time of individual samples. ASync sample atom manages, among all the samples, those from whichdecoding can be started. A Sample-to-chunk atom manages the number ofsamples contained in each chunk and which entry in the Sampledescription atom each chunk refers to. A Sample size atom manages thesize of each sample. A Chunk offset atom manages the address of eachchunk from the front of the file.

An Edit atom contains one Edit list atom as shown in FIG. 10. An Editlist atom has groups (entries) of values of Track duration, Media timeand Media rate, in an amount that is designated by Number of entries.These entries each correspond to a section that is reproducedconsecutively on a track and are arranged on the track in the order ofplayback time sequence.

Track duration represents the playback time on the track of the sectionthat is managed by the entry; Media time represents the position, in themedia data, which corresponds to the front of the section that ismanaged by the entry; and Media rate represents the reproduction speedof the section that is managed by the entry. When Media time is set at−1, playback of samples on that track is halted by the time indicated byTrack duration of that entry. This section is called empty edit.

FIG. 11 shows a practical example of Edit list, where it is assumed thatEdit list atom has the content shown in FIG. 11( a) and the samplearrangement is as shown in FIG. 11( b). Here, Track duration, Media timeand Media rate of the i-th entry are represented by D(i), T(i) and R(i),respectively. In this case, actual playback of samples is implemented inthe order shown in FIG. 11( c). This will be briefly described.

First, since entry #1 defines that Track duration is 13000, Media timeis 20000 and Media rate is 1 (FIG. 11( a)), the sample section from time20000 to 33000(=20000+13000) (FIG. 11( b)) is played back in the tracksection from the front to 13000 (FIG. 11( c)). Then, since entry #2defines that Track duration is 5000 and Media time is −1 (FIG. 11( a)),no data is reproduced from the track section from time 13000 to18000(=13000+5000) (null in FIG. 11( c)).

Finally, since entry #3 defines that Track duration is 10000, Media timeis 0 and Media rate is 1 (FIG. 11( a), the sample section from time 0 to10000 (FIG. 11( b)) is reproduced in the track section from time18000(=13000+5000) to 28000(=18000+10000) (FIG. 11( c)).

FIG. 12 shows the structure of a User-defined data atom. This atom isable to store a desired number of pieces of free information that arenot defined by the QuickTime format. A piece of free information ismanaged by one entry, which is composed of Size, Type and User data.Size indicates the size of the entry itself. Type is an ID informationfor distinguishing that free information from the others. User datarepresents actual data.

<Index File>

One special QuickTime movie file called AV index file is provided on thedisk in order to manage QuickTime movies contained in the disk.Registered in the AV index file are thumbnails and various attributesconcerning files (QuickTime movies, still images referred to byQuickTime movies, and others) in the disk.

One of the various attributes is Link count, which represents the numberof times the file is referred to from without. Checking the Link countof a file facilitates the knowledge as to whether there is any file thatrefers to that file, so that it is possible to prevent accidentaldeletion of a file that is referred to from others.

Embodiment 1

One embodiment of the present invention will be described with referenceto FIGS. 13 to 21.

<AV Stream Structure>

The structure of an AV stream in the present invention will be describedwith reference to FIGS. 13 and 14. An AV stream is composed of aninteger number of Record Units (RUs). A RU is a unit to be recordedcontinuously on the disk. The lengths of RUs are set up so as toguarantee seamless playback (the picture and sound during playback canbe reproduced without a break) regardless of how the RUs that constitutethe AV stream are allocated on the disk. This setup will be describedlater.

Further, the stream is constructed so that RU boundaries correspond toECC block boundaries. Owing to these RU features, the arrangement of anAV stream after it has been recorded on the disk can be easily changedby the RU units while seamless playback is guaranteed.

A RU is composed of an integer number of Video Units (VUs). A VU is aunit that is reproducible by itself. Therefore, it is a possible entrypoint upon reproduction. FIG. 14 is the structure of a VU. A VU iscomposed of an integer number of GOPs (groups of pictures) storing videodata of about one second long and an integer number of AAUs (AudioAccess Units) storing main audio data to be reproduced in synchronism.

Here, GOP is a compression unit in MPEG-2 standard and is composed of amultiple number of video frames (typically, about 15 frames). AAU is acompression unit in MPEG-1 Layer II standard, and is composed of 1152sample points of the sound waveform. When the sampling frequency is 48kHz, the reproduction time per AAU is 0.024 second.

In VU, AAUs and GOPs are arranged in the order mentioned in order tolessen the necessary delay to assure AV synchronized reproduction.Further, in order to permit independent reproduction in UV units, aSequence Header (SH) is allotted at the front of the video data in eachVU.

The playback time of a VU is defined by the product between the numberof video frames contained in the VU and the video frame period. When aninteger number of VUs are put together into a RU, zeros are stuffedafter the end of the VUs so that the start and end of the RU correspondto ECC block boundaries.

In the present embodiment, the AV stream structure shown in FIGS. 13 and14 is used for explanation, but the present invention should not belimited to this stream configuration.

<AV Stream Management Method>

The management method of AV streams is devised on the basis of theaforementioned QuickTime file format. FIG. 15 shows an AV streammanagement structure by QuickTime. AAU is given as a ‘sample’ f audiodata, and Sequence header and the integer number of GOPs are given as a‘sample’ of video data. The main audio and the video block in VU areeach made correspondent to a single chunk.

<Determining Method of Allocation on Disk>

The determining method of allotting AV streams on the disk will bedescribed. In order to guarantee seamless playback, the RU readout timeincluding the time for jump to the next RU needs to be shorter than theplayback time of a RU.

This means that Te(i), the RU playback time, satisfies the followingrelation:

Te(i)≧Tr(i)   <Eq. 1>

where Te(i) is the RU playback time, T(i) is the maximum playback timefor an arbitrary RU in AV streams, namely RU#i, and Tr(i) is the maximumreadout time including the time for discontinuous jump.

When Ra and Rv represent the maximum bit rates of the main audio andvideo in the AV streams, Ta represents the maximum access time of theplayback device and Rs represents continuous readout rate, the followingrelation holds:

Tr(i)=Te(i)×(Rv+Ra)/Rs+Ta   <Eq. 2>

From <Eq. 1> and <Eq. 2>, Te(i) should satisfy the following relation:

Te(i)≧Ta×Rs/(Rs−Rv−Ra)   <Eq. 3>

Therefore, the minimum value Temin for the RU playback time to guaranteeseamless playback is given as follows:

Temin=Ta×Rs/(Rs−Rv−Ra)   <Eq. 4>

<Process for Recording>

Referring to FIG. 16, the process when recording is commanded by theuser will be described. In this case, it is assumed that the AV streamto be recorded has a video bit rate Rv=5 Mbps and an audio samplingfrequency of 48 kHz with a bit rate Ra=Rp=256 kbps. It is also assumedthat the management information of the filesystem has already beenloaded into RAM.

To begin with, the stream configuration and the arrangement ofcontinuous areas are determined (Step 701). When it is assumed that 1 VUis composed of 1 GOP=30 frames, as a result of substitution of Rs=20Mbps, Ta=1 sec., Rv=5 Mbps and Ra=256 kbps into <Eq. 4>, Te(i) is givento be equal to or greater than 1.36 sec. Since the playback time of 1 VUis 0.5 sec., the RU playback time is set at 2 seconds.

Next, an empty area capable of recording two consecutive VUs should besearched for. Specifically, 2×(Rv+Ra), or a continuous empty area equalto or greater than 11 Mbits should be searched for with reference toSpace Bitmap in RAM 102. If there is no such a space, the recording isstopped and failure of recording is informed to the user (Step 702).

Audio encoder 117 and video encoder 118 are activated (Step 703). Next,it is checked whether data in an amount equal to or greater than one ECCblock (32 KB) is accumulated in the recording buffer (Step 704). Whiledata accumulation is in progress, Steps 705 to 708 are repeated.

When data accumulation is completed, the status of vacancy of the nextECC block to which data is recorded on the disk is checked withreference to Space Bitmap in RAM (Step S705). If there is no vacancy, anempty area capable and the pickup is moved to the front of that emptyarea (Step 708).

Next, data in the amount of one ECC block from recording buffer 111 isrecorded into the disk (Step 706). If data has not been accumulated inrecording buffer 111, it is checked whether a recording end command hasbeen given (Step S709). When recording has not yet ended, Step 704 isexecuted.

When a recording end command has been given, the following steps areimplemented. First, the data in the recording buffer, in an amount under32 KB is added at its end with dummy data to reach 32 KB (Step 710).Next, the data is recorded onto the disk (Steps 711 to 714). Finally,the QuickTime management information (Movie atom) in RAM 102 and thefilesystem management information are recorded on optical disk 106(Steps 715 to 716).

The operations of audio encoder 117, video encoder 118 and multiplexer113 which operate in parallel with the above process will be described.Each of the encoders sends the encoded result to multiplexer 113 and themultiplexer stores these into multiplexing buffer 114.

When data amounting to 1 VU, or 1 GOP with AAUs to be reproduced insynchronism therewith are accumulated in multiplexing buffer 114,multiplexer 113 sends out data of 1 VU to recording buffer 111. Then,notice that data corresponding to 1 VU has been encoded is given to hostCPU 101, host CPU 101 renews the QuickTime management information in RAM102, based on the GOP that constitute the VU and the number and sizes ofAUUs.

<Process for Editing>

A case where data in RU units is deleted from a portion partway withinan AV stream will be considered. As already mentioned, the RU boundariescorrespond to ECC block boundaries. Further, one ECC block is composedof 16 sectors, and one sector corresponds to one logical block.Accordingly, it is possible to delete RU units of data by only rewritingthe filesystem management information and the QuickTime managementinformation.

As to the filesystem management information, those bits that correspondto the area to be deleted, in the aforementioned Space bitmap, are setat 0 to thereby release the area while the extents that manage the RUsto be deleted are rewritten. As to the QuickTime management information,the samples contained in the section to be deleted are deleted from theSample table and the Chunk offset value of the chunk located after thesection to be deleted is reduced by the number of bytes of the deletedsection.

Further, with the reduction in playback time of each track due todeletion, Track duration of Edit list (FIGS. 10 and 11) should beshortened (FIGS. 10 and 11). By the above deletion, the resulting AVstream is formed so that the points right before and right after thedeleted section are joined. At the same time, as to the video track, inorder to demonstrate the seam, different entries are allotted before andafter the point of time corresponding to the seam between the areasbefore and after the seam.

For example, when AV streams #1 and #2 are joined so as to constitute anAV stream as shown in FIG. 17, Edit list atom (FIG. 10) is defined bytwo entries as shown in FIG. 18. Also, a case where AV streams arejoined to one another in RU units can be also handled in a similarmanner to that of deletion, i.e., by rewriting the filesystem managementinformation and the QuickTime management information. From thisinformation, the point of time at the seam along the track time axis andthe address of the corresponding data of the time in the file can beknown.

Though in the present embodiment, a case including one seam wasdescribed, it goes without saying that a case including two or moreseams can be dealt with by only increasing the number of entries.

In the above case, the seam is made distinct by switching the entries inthe Edit list of one track of video. However, any method can, of course,be used as long as it is possible to make distinct the possible sitesthat originate from the junction of AV streams and that may hinderdecoding and reproduction. To cite one example, seams can be indicatedby switching video tracks every seam.

Illustratively, in a case where AV streams shown in FIG. 17 are createdby a joining process, the seam can be made distinct by managing thefront half and the rear half using different tracks in such a mannerthat the contents of the Edit list atoms (FIG. 10) of the tracks thatmanage the front and rear halves are designated respectively as shown inFIGS. 19( a) and 19(b). In this case, in order to prevent accidentalintegration of the video tracks #1 and #2 after post editing, at leastone value, specifically, Creation time (FIG. 5) or the like, is madedifferent between video tracks #1 and #2.

Alternatively, the seam may be demonstrated by making the content ofSample description atom (FIG. 9) different between that before and afterthe seam. Specifically, in a case where AV streams shown in FIG. 17 arecreated by a joining process, the video data of the AV stream #1 and thevideo data of the AV stream #2 are adapted to refer to separateattributes represented by different entries #1 and #2 in Sampledescription atom, as shown in FIG. 20.

In this way, it is possible to show the seam. Further, bydifferentiating at least one value of each entry from that of the otherin Sample description atom, it is possible to prevent the entries #1 and#2 from being accidentally merged when the Sample description table isoptimized (plural entries having common content are integrated into one)at a later editing process.

<Process for Playback>

The process when a playback command is given from the user will bedescribed with reference to FIG. 21. Here, it is assumed that theQuickTime management information on the AV stream to be reproduced hasalready been loaded into RAM 102.

Playback data starts being read from the front of a designated VU onoptical disk 106 for playback (Step 901). This step 901 is repeateduntil a sufficient time of playback data has been loaded to playbackbuffer 110 (Step 902).

‘A sufficient time of playback data’ herein means the amount of datathat will not cause any break during playback even when the maximuminterruption occurs during readout of playback data. Specifically, theamount of data for 1 second is secured assuming that a discontinuousjump (maximum 1 second) entailing the readout of AV data is made.

Next, host CPU 101 activates video decoder 116 and audio decoder 115(Step S903). Host CPU 101, based on the QuickTime managementinformation, gives a command to demultiplexer 112 so as to transfer theencoded data from playback buffer 110 to audio decoder 115 and videodecoder 116.

Also, it is checked whether a playback end command has been given fromthe user. (Step 904). If no command is given, playback AV data is readout (Step 905). If the playback end command has been given, theoperation is ended.

When host CPU 101, based on system clock 105, detects that the currenttime reaches the time for switching the entries (FIG. 11) of Edit listatom (FIG. 10) of the video track, it determines that the site is a seamand halts the decoding operations by video decoder 116 and audio decoder115. When change of the entries in Sample description table (FIG. 20) towhich the video chunks refer is made use of to indicate a seam, the siteat which change of the entries occurs is determined to be a seam.

Though the above operation causes the video frame right before the seamto be displayed (frozen) multiple times consecutively, no bufferunderflow will occur because data can be accumulated into the decoderbuffer for video decoder 116 during this period. Therefore, noreproduction noise will occur for some time, unlike the decoder bufferunderflows. Further, since the video picture across a seam is inherentlydiscontinuous, a freeze, if it occurs, will not cause noticeable noisecompared to the same event at any other site.

Though in the present embodiment a single video decoder is used, amultiple number of video decoders may be used to make a switch at aseam. Specifically, the following operation is effected upon playback.Because the position of an actual seam in the AV data is known from thechange of the entries in Edit list atom of the video track, the videodata after the seam is sent to other video decoder than that used beforethe seam and starts being decoded so that the data can be displayed atany time. Then, when it reaches the point in time at which the entriesof Edit list atom are switched, the video decoders are switched fromthat before the seam to that after the seam. In this case, sincedifferent decoders are used before and after the seam, no discontinuityof the occupancy of the VBV buffer will occur, and it is no longernecessary to freeze the display as in the case where only a single videodecoder is used.

Though in the present embodiment the seams generated during editing arehandled, the seams to be managed by the present invention are notlimited to only those arising during editing. For example, whenrecording of a new AV stream is added after the end of an existing AVstream file, a discontinuity of the amount of occupancy of the VBVbuffer occurs between the point before and after the point of addition.If the AV stream file is reproduced as is, there is a risk of noiseoccurring in decoding and reproduction right after the point ofaddition. Management of the point of addition in the same manner as inthe present embodiment makes it possible to prevent such decoding andreproduction noise.

As has been described heretofore, according to the present invention,when multiple AV streams are put together into a single AV stream, thepositional information of the seams are managed by the managementinformation that manages the AV stream. Thereby it is possible toprevent the display from being disturbed around the seams whenreproduced.

INDUSTRIAL APPLICABILITY

When AV streams of video data, audio data, etc., are recorded into arandom accessible recording medium such as a hard disk, optical disk orthe like and decoded therefrom, the invention is suitable for datarecording, editing and decoding methods and a device thereof that canprevent playback data noise occurring between the AV streams.

1-15. (canceled)
 16. A data recording method for recording an AV streamcontaining at least video data, program information as to the AV stream,and filesystem management information for managing the AV stream and theprogram information as respective files, onto a recording medium,wherein the AV stream is managed as a single file, and the programinformation contains first track information corresponding to a firstsection that is capable of reproducing consecutively in the AV stream,the method comprising the steps of: deleting a second section from thefirst section, first rewriting for rewriting the filesystem managementinformation so that the points right before and right after the deletedsecond section are jointed in the AV stream, and second rewriting forrewriting the program information in such a manner that different tracksinformation are allotted before and after the point of junction, inorder to indicate the point of junction.